The Remote Access Dial-In User Service (RADIUS) is an AAA client-server protocol. RADIUS is the de facto industry standard for remote access AAA, as well as an Internet Engineering Task Force (IETF) standard. In general, RADIUS is a network process that performs authentication, authorization, and accounting actions when a user logs in on a Network Access Server (NAS) with a dial-up client, or logs out from the NAS. Typically, a RADIUS server is used by Internet Service Providers (ISPs) to perform AAA tasks. AAA tasks include verifying the identity of an entity (authentication), determining whether a requesting entity is allowed to access a resource (authorization), and collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation (accounting). The RADIUS server may also be used when controlled dial-up access is needed in a particular organization. A technical specification of basic features that are supported by all RADIUS servers can be found in RFC 2865/RFC 2138 and RFC2866/RFC 2139, which are hereby incorporated by reference herein.
Existing AAA servers perform RADIUS proxy functions using static configuration tables stored in the AAA server. The static tables do not change at run-time. The AAA server typically uses the realm or the Access Point Name (APN) included in an incoming message to determine whether or not to forward the message. The realm is a part of the Network Access Identifier (NAI) that is included in the User-name attribute. According to Third Generation Partnership Project (3GPP) specifications, the APN is included as the value of the Called-Station-ID attribute. The address of the Network Access Server (NAS) is included in the NAS-IP-Address attribute.
In addition to the classic AAA functions, AAA servers may also perform session management functions such as hosting master sessions. A master session is a session created when a user is successfully authenticated by the system. The master session is terminated when the user logs off. The master session is created in a home AAA server, which hosts the data of the user to which the master session is tied. Anonymous master sessions, that is, sessions that are not bound to a user, may be created in any AAA server.
In addition to the classic RADIUS proxy functionality, there are a number of known alternative methodologies to enable a client to find the AAA server that hosts a given user. In one such methodology, the location of the AAA server is stored in an external repository such as a directory service. The directory service provides a discovery service to the client. When the client desires to access an AAA server, the client queries the directory to discover the appropriate AAA server. Afterwards, the client sends its request to the AAA server.
In another methodology enabling a client to find the AAA server that hosts a given user, all of the AAA servers that host user data (the AAA infrastructure) locate the specific AAA server when a request is received. RADIUS proxy functionality is implemented in each AAA server, and a load-balancing device randomly sends the request to any AAA server. When the AAA server receives the request, the server determines whether it is the appropriate AAA server to process the request. If not, the AAA server queries the directory service and, depending on the answer, forwards the request to the appropriate AAA server.
In another methodology enabling a client to find the AAA server that hosts a given user, the responsibility for finding the appropriate AAA server is again handled by the AAA infrastructure. A routing node contains a global directory database with the per-user locations of the AAA servers, together with a RADIUS stack and the capability of performing RADIUS proxy functions. The client sends its requests to the routing node, which looks up the appropriate AAA server in its database, and forwards the request.
The existing static routing methodologies have several shortcomings. As the number of users grows, the number of AAA servers must grow to host the users' data. When an AAA server plays the role of session manager, the existing static routing methods (based either on internal tables or external look-ups) do not support the location of the appropriate AAA instance handling the user requests for a specific session. When a client wants to access a given master session, the only parameter that is available to look it up is the master session identity (ID) because no user identity is provided. However, the master session ID is a dynamic value generated at run time, and has special features (i.e., random, unique, not reusable, and unpredictable). The routing data used by the static routing methods is based on pre-configured static tables or databases that are not updateable at run time. Thus, there is no way to determine where a master session is stored.
Similar drawbacks to those stated above may be experienced when using a Lightweight Directory Access Protocol (LDAP) interface to access a central, and likely external, repository from a first-queried AAA server that is not in charge of a given user, in order to determine the appropriate AAA server where the query should be redirected.
It would be advantageous to have an AAA server that overcomes the above-described shortcomings. The present invention provides such an AAA server.